The responses or views reflected in these questions are solely that of Merchant Link. Readers are advised to consult their own legal and technical advisors before undertaking any PCI-compliant programs.
Question Categories (and excerpts from each one):
- Card Associations
- What can be done about V/MC making up all the rules?
- Can the merchant banks or credit card institutions legally charge fines for non-compliance?
- What are the credit card companies doing to help relieve the heavy lifting that has to be done by merchants to keep card data secure?
- What was the Visa website (referenced during webinar) to check compliance of your system?
- When are credit card processors and the credit card companies going to work together to provide merchants PCI solutions?
- Compliance Concerns
- What type of language should be included in vendor contracts to capture any PCI compliance required?
- How should a small restaurant with a limited budged implement a customer authentication system with logs?
- Do you envision heavier enforcement at some point?
- With 3rd party payment software, what is our exposure if there is a security breach?
- Is the POS provider required to provide their PCI compliance policies?
- What is the cheapest way to achieve compliance?
- What liability do vendors assume when merchants do not upgrade their POS software?
- If you use a stand-alone terminal and do not use Internet access would you be PCI compliant, since we are not storing any data?
- If we use a processor does that mitigate exposure since they track all these regulations?
- Please comment on compliance for peripheral devices such as RFID Readers, MSRs, and their connections to cash registers.
- Is compliance mostly focused on the logging of who and when, or is it more a matter of how secure the software application is or both?
- Encryption
- Enterprise
- What additional exposure, if any, do we face if we have multiple POS systems processing credit cards?
- How do we determine at what point our brand begins to become liable?
- PCI-DSS
- What does it take to have our POS software accredited to be PCI certified?
- What can a customer do if we are not complying with the new rules?
- Why are the standards so hard for small businesses to follow?
- Is there a cutoff date for when an end user will be liable for not changing their POS system?
- Is there an effort to implement the "removal" of card data at the swipe in order to limit exposure?
- POS Software
- Security
- How can you think ahead and properly prepare to keep your card data out of harm's way?
- My concerns are primarily focused around remote access to the back office PCs at our stores.
- What are the security risks if we have surveillance systems accessed remotely via the network?
- How will credit card security change how we do business day to day?
- What do you do if your POS supplier allows managers to view all credit card numbers, etc.?
- Regarding requirement 6.6, how is a web app firewall different from the firewall requirements set forth in Req 1?
- Skimming/Sniffing
- How do you detect and what can be done about "swiping" devices that can be attached to a terminal which steals the credit card strip information?
- Is employee theft still a problem in the restaurant business even with all the new technology?
- Is the PCI Council going to require encryption of track data on the LAN?
- Storage
- Does store-and-forward on the POS typically constitute a PCI exposure?
- What are the storage requirements for credit card payment receipts or reports?
- What information is available to us to research customer charge-backs?
- Differentiate requirements for networks that are not accessible from the Internet (RFC1918) versus networks that are accessible.
- Is holding track 1 data for the current business day an acceptable practice?
- Does a standalone credit card terminal store data?
- How long should you keep signature slips?
- If you store truncated CC transactions on a back office PC is it considered "storing" customer info?
- How do you comply with the "not storing data requirement" if you are under a court order to retain sales data?
- If we are storing PAN data and not track data, is that still a problem?
- You emphasized the importance of not storing the data and shooting it directly to the host but our processor states that they also understand this. What should we do to build a truly host based solution that does everything possible to transmit card holder data immediately after the credit card swipe?
- What if your system crashes & you have to take orders & payments manually?
- Other
Card Associations
The rules are established to protect the cardholder's interest and the integrity of the financial system. Government intervention would be the only likely path that would impact the creation of rules. Yet, Government intervention would likely increase the cost to the entire system since intervention is typically accompanied by the creation of a new agency (IRS, TSA, FDA, etc) and a new set of rules and regulations. As onerous as the V/MC rules appear to be, they may well be better than the alternative.
Merchants sign agreements that state that they will abide by Association rules and allow merchant acquirers to pass along fees imposed by the Card Associations. Therefore, each merchant authorizes the activity. Nevertheless, operating a non-compliant network opens the business to significant risk, irreparable brand damage and customer losses.
The card associations created the PCI Data Security Standards to protect the cardholder. They created the Payment Application Data Security Standard to require software providers to develop applications that support a merchant's compliance. Unfortunately, nothing has been done to standardize systems, networks, and operating procedures that would be required to relieve the heavy lifting - so the burden does indeed fall on the merchant.
http://www.visa.com/cisp
The Card Associations have created the data security standards to protect cardholders. Card Associations also are trying not to endorse one company or method over another. I believe that it is their expectation that the free market will create solutions that will be employed by franchisors and merchants. While the process does seem onerous and can certainly be costly, we believe in the end it is preferable over government-sanctioned requirements and regulations. But this is also why Merchant Link recommends going "beyond PCI compliance" - because a merchant or franchisor should do everything it can to protect and grow its brand, reputation and customer base.
Compliance Concerns
By all means, restaurant operators should include in their technology vendor contracts language which covers vendor roles and responsibilities vis-a-vis PCI compliance. That said, we would recommend that you consult with an attorney and your payments acquirer for specific language that designates that service providers maintain PCI DSS compliance as required and that POS providers maintain PA DSS (Payment Application Data Security Standards). Additionally, all vendor-provided products and services to a merchant's network environment should support that merchant's compliance with PCI DSS.
Authentication and logging issues are addressed when the restaurant selects a validated payment application. If the merchant does not want to store cardholder data, a compliant swipe device that provides an authorization code and a paper receipt of the transaction is another option. The merchant will only have to ensure the paper copies are kept in a secure location with limited access.
Yes, it appears that the Card Associations are beginning to take significant action to influence compliance within the largest of companies by issuing fines and penalties to merchant acquirers, which are then passed through to the merchant. New rules have been established that prohibit the use of non-compliant applications, which will inevitably increase the burden on smaller merchants. As small merchants remain the leading target of hackers, it is reasonable to assume that further pressure will be applied to drive compliance with the standards. The upshot of all of this is that merchants of all sizes must begin - if they haven't already - to assess where they are, and where they are headed, with regard to PCI compliance.
PCI compliance is the responsibility of the merchant accepting the payment. Third-party payment software may work just fine, but we would suggest that you ensure the product meets the standards of PCI DSS.
PCI-compliant POS providers must provide implementation guides that document proper implementation procedures to support a merchant's PCI compliance. It remains the merchant's responsibility to install and maintain the system in a compliant manner.
With all due respect, the cheapest way is to only accept cash. Since that is not an option for most businesses without jeopardizing sales revenue, it remains important to look at compliance as an ongoing journey. Focus more on the security of your customers, your systems, your reputation and your brand, than on compliance. If budgetary constraints do not allow you to make broad sweeping changes, attack your biggest risks/vulnerabilities first by outsourcing or encrypting cardholder data.
It is the merchant's responsibility to maintain PCI compliance. Good vendors can and should help their customers achieve PCI compliance, but typically they are not held liable for their actions - or inactions. If a merchant fails to upgrade to a compliant system, the merchant owns the liability.
POS systems that are sold to merchants are in scope for PABP / PA-DSS. Click to review "Scope of PABP" here: http://usa.visa.com/download/merchants/cisp_payment_application_best_practices.doc
No. The merchant alone is responsible for its PCI compliance. PCI compliance relates to the merchant's systems and network. Processors are unaware of the details of each merchant's unique implementation. That said, there are others, including processors, banks and vendors, who can certainly help you.
Only PCI-compliant peripherals should be used to support the merchant's compliance. . Each device manufacturer should be able to present information on how their device supports PCI requirements.
Compliance is focused on securing the cardholder data. Access control and application vulnerability are just two of the components involved.
Encryption
Pay-at-the-table devices reduce skimming and provide the consumer with a level of confidence that their information is secure. That being said, with respect to tableside payment terminals, wireless solutions must be secured with the latest wireless security protocols to eliminate a significant amount of vulnerability.
Enterprise
The exposure is limited to the extent of the loss of data, irrespective of the number of systems.
That is a huge question, but your brand's importance begins the minute the sign hangs above the door. As you accurately state, the court of public opinion casts a wide verdict and rarely focuses on the franchisee but rather on the franchisor. Relative to PCI compliance, unless the franchisor is aggregating payments (all stores send transactions to corporate) and/or processing more than 6 million Visa transactions, the franchisee is liable for the financial impact of a data security breach. That franchisee is then elevated to a Level I merchant and must undergo all of the rigors of the world's largest retailers. We recommend franchisors undertake a dedicated franchisee communications and education effort to signify the importance of the security issue, and to help convince franchisees that it is in everyone's best interest to achieve PCI compliance and beyond.
PCI-DSS
Purchased software should be certified as compliant with the Payment Application Data Security Standards (PA DSS). The software provider completes the certification by engaging an accredited auditor to perform the audit for the Card Associations. Once certified, the application is placed on the certified list available at http://www.Visa.com/cisp. Check with your software provider to see if they are accredited, or have applied for accreditation.
Referring to PCI DSS, non-compliant merchants can be fined by the Card Associations. Relative to printing receipts with a portion of the card number and the expiration-you are subject to a lawsuit and fines from the Federal Trade Commission!
Please believe me when I say that PCI compliance standards are just as hard for small businesses as they are for large. Unfortunately, security has become increasingly difficult and complex because systems have become more complicated and hackers have gotten more sophisticated. Because of this, the PCI compliance standards are like a bar in a high jump competition that continues to be raised, regardless of the number or fitness of the athletes attempting to clear it.
The data has long expired. ALL MERCHANTS must be compliant now and are responsible for fines, penalties, and other liabilities related to a data security breach. Please refer to standards page of the PCI Council: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Electronic payment vendors continue to introduce compliant devices and encryption software solutions into the marketplace to reduce and, in some cases, eliminate cardholder data storage. Visa issued a security brief to review the improper storage of cardholder data and recommended mitigation strategies that can be found at: http://broadcast01b.visabroadcasts.com/doc/20080903103002/2b74458b23d0890b336479d6e0aebc34
POS Software
There are many steps to PCI compliance. The way to determine your compliance level is to review them at https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml. Then complete the appropriate self assessment questionnaire (https://www.pcisecuritystandards.org/saq/index.shtml). If you can answer the questions and justify compliance, you may consider yourself compliant. Just remember, PCI compliance is really a journey without a destination. As new technologies are created and hackers become more sophisticated, new vulnerabilities are introduced - and new PCI requirements will inevitably be mandated.
Security
As we discussed on the QSR webcast, staying ahead of the hackers – moving beyond PCI compliance – requires an ongoing commitment by operators, their vendors, processors, banks and the card associations. That said, we believe the leading way to keep card data out of harm’s way is to eliminate it. Hackers cannot appropriate what’s not there! A variety of solutions are available as outsourced options and discussed by leading IT analysts, Javelin (see their report on "PCI Compliance: Finding Value beyond Fine Avoidance.”) and Gartner. In addition, we recommend you take action on all of the components of PCI DSS including implementation of a fire wall, controlling access to applications, and regularly updating virus protection.
We recommend merchants only use applications that support their compliance, and possess the ability to limit access to authorized users. It's probably a good idea to institutionalize a formal staff and vendor security training program, and to provide periodic "refreshers" to ensure all who have access also understand the changing nature of security threats.
This depends upon your network segmentation. You should consult your network engineer to ensure that you do not have a 'flat' network where all users have access to all systems. Cardholder data should be segmented to reduce access to only those systems and users that really require access.
Security will certainly change the way you do business. You wouldn't consider leaving your safe open and your doors unlocked. Consider the point of sale as your virtual business where a hacker can steal from you and your customers through a wire. Indeed, you need locks and a secure safe in the electronic world as well. The bottom line for merchants, however, is that they never can become complacent, even if they become compliant!
Our advice would be to get a new POS system. If a manager can see it, odds are that a hacker can get to it also.
PCI 6.6 only requires a web application firewall for systems that are in-scope for PCI, so if an organization does not have a web presence that stores, transmits, or accepts credit card data, it does not need a web application firewall. Normal firewalls inspect traffic from a network level, but cannot generally make decisions about the actual content of the traffic. For example, a normal firewall can determine that one computer has requested a web page from another, but it cannot make judgments on the content of said web page. Web application firewalls inspect the contents of the web site and protect against common attacks such as SQL injection, buffer overflow, and cross-site scripting attacks.
The only alternative that the PCI standards provide is a code review by a qualified third party to ensure that the code of the web site is not vulnerable to attack.
Skimming/Sniffing
Unfortunately, the majority of breached merchants don't realize that they have been breached until they are contacted by the Card Associations. 'Swiping' or skimming is difficult to detect because most of the devices are mobile and carried in the pocket of dishonest associates. The only truly effective way to detect this kind of activity is to raise awareness among your employees, and to ensure that they know to report any odd or suspicious devices or activities among other employees.
Unfortunately, yes. Portable devices that 'skim' credit card data can be used by dishonest employees to steal consumer information. They are difficult to detect. Also, if a merchant's system is not adequately secured, an employee can gain access to improperly stored credit card data. The best and perhaps only way to combat against these practices is to train all employees to recognize and report suspicious behavior.
Installation of packet sniffers starts with other vulnerabilities that should be addressed in the creation of a secure environment. For example, access controls, firewalls, virus protection, and log monitoring should be employed to prevent installation of unauthorized applications that would sniff data.
Storage
The Card Associations allow for the storage of all card data, including track II data (normally prohibited), prior to authorization. Therefore, unauthorized transactions can be stored. However, we recommend that track data not be stored, and any store-and-forward transactions be processed as keyed transactions (the POS would only have to store the card number and expiration date, not the track data).
This is a business decision. Card Association rules allow consumers to chargeback transactions for up to 6 months from the date of purchase. In order to defend yourself against charge-backs, a signed receipt that contains the truncated or masked account number is required.
Within compliant systems, cardholder data is typically masked and restricted to prohibit adequate research. Relative to the offsite storage or outsourcing of data within TransactionVault™, encrypted systems are maintained to help merchants identify the original cardholder information for the purposes of responding to charge-backs.
Fundamentally, if a network is not accessible from the Internet or outside world, cardholder data must be secured from physical theft (stealing the hard drive) and unauthorized access (downloading to a flash drive).
All cardholder data should be encrypted or outsourced for storage, regardless of the period of time it is held. The impact of storing a day's business is small until you consider a recurring theft of daily business, which increases the risk.
It is a business decision to support your ability to respond to charge-backs. Card Association rules allow the cardholder 6 months from the date of purchase to dispute a charge. Note that if you are retaining information that contains the credit card number, the paper documents must be secured and access limited.
It depends. Some 'truncated' data means that you cannot see it. It does not necessarily mean that it isn't there and accessible by outsiders. You need to confirm that your system does not store data by contacting your POS dealer.
Card holder data must be protected. There is not a rule that states 'do not store...'- but it's a smart policy. If you must store data (Track I only), it must be protected. You can protect the data by encrypting it or outsourcing the storage of card data to a reputable firm.
If you store data, it must be secured. Merchants connecting their payment applications to the Internet using an IP POS terminal that does not store card data and only accepts card-present transactions are considered PCI SAQ Validation Type 4 and use SAQ C, which has 34 security questions. If the terminal stores card data (PAN) the merchant is considered PCI SAQ Validation Type 5 and use SAQ D, which has 234 security questions.
Most QSR point-of-sale systems were built to support batch processing, where the system stores transactions for a period of time and settles them in bulk at a specified period. Excluding considerations about chargeback defense and other business needs, conversion to a host-based point-of-sale would be required to effectively eliminate the storage of data. Conversion to a host-based system does not mitigate the other 11 requirements of PCI compliance. Nevertheless, any system that stores, transmits, or processes credit card data remains in scope for PCI compliance.
Hand written card information should be secured and shredded once the business need to retain it has passed.
Other
Yes, a customer name and expiration date can appear on a receipt. However, according to FACTA rules, no portion of the credit card number can be displayed if the expiration date is printed.
Prices vary from vendor to vendor and have an estimated range from $25 to $100 per scan depending upon the complexity of the network being scanned and the complexity of the scanning process desired.
No receipt equals no real defense. Your processor may be able to create a 'substitute draft,' but it is unlikely that the cardholder's bank will accept it.
